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Report of the IAB Security Architecture Workshop 


1. Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


2. Copyright Notice 


Copyright (C) The Internet Society (1998). All Rights Reserved. 


3. Abstract 


On 3-5 March 1997, the IAB held a security architecture workshop at 
Bell Labs in Murray Hill, NJ. We identified the core security 
components of the architecture, and specified several documents that 
need to be written. Most importantly, we agreed that security was 
not optional, and that it needed to be designed in from the 
beginning. 


3.1. Specification Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 


4. Motivations 


On 3-5 March 1997, the IAB held a security architecture workshop at 
Bell Labs in Murray Hill, NJ. The ultimate goal was to design a 
security architecture for the Internet. More concretely, we wished 
to understand what security tools and protocols exist or are being 
developed, where each is useful, and where we are missing adequate 
security tools. Furthermore, we wanted to provide useful guidance to 
protocol designers. That is, if we wish to eliminate the phrase 
"security issues are not discussed in this memo" from future RFCs, we 
must provide guidance on acceptable analyses. 
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There were twenty-four attendees (their names are listed in Appendix 
A). Perhaps not surprisingly for such a group, the overwhelming 
majority used some form of cryptography when connecting back to their 
home site from the meeting room. But the situation on the rest of 
the Internet is not nearly as good; few people use encryption, even 
when they should. 


The problem is that the rate of attacks is increasing. Apart from 


the usual few elite hackers -- the ones who find the new holes -- 
there are many canned exploit scripts around. ("Click here to attack 
this system.") Furthermore, the attackers have gotten smarter; rather 


than going after random university machines, more and more are 
targeting the Internet infrastructure, such as routers, high-level 
name servers, and the like. 


The problem is compounded by organizational laziness. Users and 
system administrators want "magic security" -- they want whatever 
they do to be secure, regardless of whether or not it is, or even can 
be. 


5. General Philosophy 


We concluded that in general, end-to-end security is better. Thus, 
one should use something like PGP or S/MIME for email, rather than 
relying on an IPsec layer. In general, relying on the security of 
the infrastructure is a bad idea; it, too, is under attack. Even 
firewall-protected intranets can be subverted. At best, the 
infrastructure should provide availability; it is the responsibility 
of individual protocols not to make unreasonable demands on the 
infrastructure during an attack. 


6. IETF Structure 


Our security problem is compounded by the IETF’s inherent structure 
(or, in some cases, the lack thereof). By intent, we are a volunteer 
organization. Who should do the security work? The other protocol 
designers? Often, they have neither the time nor the interest nor 
the training to do it. Security area members? What if they are not 
interested in some subject area, or lack the time themselves? We 
cannot order them to serve. 


To the extent that the IETF does have management, it is embodied in 
the working group charters. These are in essence contracts between 
the IESG and a working group, spelling out what is to be done and on 
what schedule. Can the IESG unilaterally impose new requirements on 
existing working groups? What if security cannot be added on without 
substantial changes to the fundamental structure of a protocol that 
has been reworked over several years? 
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Finally, there is a perception problem: that IPsec will somehow 
solve the security problem. It won't; indeed, it can’t. IPsec 
provides excellent protection of packets in transit. But it’s hard 
to deploy on individual hosts, does not protect objects that may be 
retransmitted (i.e., email messages), does not address authorization 
issues, cannot block against excess resource consumption, etc. 


7. Documents to be Written 


Collectively, we decided on several documents that need to be 
written: 


Taxonomy of Attacks 
In order to defend a protocol against attacks, one must, of 
course, know the kinds of attacks that are possible. While the 
specifics differ from protocol to protocol, a number of general 
categories can be constructed. 


Implementation Hints and Pitfalls 
Even if a protocol is sound, a host running it can be 
vulnerable if the protocol is implemented improperly. A 
variety of common errors can and do subvert the best designs. 


Firewall Issues 
Firewalls are both a common defense and a much-reviled wart on 
the Internet. Regardless, they are unlikely to go away any 
time soon. They have both strengths and weaknesses that must 
be considered when deploying them. Furthermore, some protocols 
have characteristics that are unnecessarily firewall-hostile; 
such practices should be avoided. 


Workshop Report 
This document. 


8. Working Group Charters 


The actual text in the working group charter is likely to be 
something fairly simple, like 


Protocols developed by this working group will be analyzed for 
potential sources of security breach. Identified threats will be 
removed from the protocol if possible, and documented and guarded 
against in other cases. 


The actual charter text represents a policy enjoined and enforced by 
the IESG, and may change from time to time and from charter to 
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charter. However, it essentially references and asks for text in 
documents conforming to the following, which may be very appropriate 
to include in the RFC. 


9. Guidelines on writing Security Considerations in an RFC 


A "threat" is, by definition, a vulnerability available toa 
motivated and capable adversary. CERT advisories are quite 
predictable given a knowledge of the target of the threat; they 
therefore represent an existence proof, but not a threat analysis. 
The point is to determine what attacks are possible ("capabilities" 
of a potential attacker) and formulate a defense against the attacks, 
or convincingly argue that the attack is not realistic in some 
environment and restrict use of the protocol to that environment. 


Recommended guidelines: 


All RFCs - MUST meaningfully address security in the protocol or 
procedure it specifies. It MUST consider that it is giving its 
data to "the enemy" and asking it to be delivered to its friends 
and used in the manner it intended. Consideration MUST be given to 
the ramifications of the inherent danger of the situation. 


- MUST do "due diligence" to list the threats to which the 
protocol is vulnerable. Use of legal term does not imply legal 
liability, but rather the level of responsibility expected to be 
applied to the analysis. This discussion might occur throughout 
the document or in the Security Considerations section; if it 
occurs throughout, it MUST be summarized and referenced in the 
Security Considerations section. 


- MUST discuss which of those threats are 
* Ameliorated by protocol mechanisms (example: SYN attack is 
ameliorated by clever code that drops sessions randomly when 
under SYN attack) 


* Ameliorated by reliance on external mechanisms (example: TCP 
data confidentiality provided by IPSEC ESP) 


* Irrelevant ("In most cases, MIBs are not themselves security 
risks; If SNMP Security is operating as intended, the use of a 
MIB to change the configuration of a system is a tool, nota 

threat. For a threat analysis of SNMP Security, see RFC ZZZZ.") 


* Not addressed by the protocol; results in applicability 


statement. ("This protocol should not be used in an 
environment subject to this attack") 
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10. Core Security Mechanisms 


A variety of security mechanisms exist today. Not all are well- 
designed; not all are suitable for all purposes. The members of the 
workshop designated a number of protocols as "core". Such protocols 
should be used preferentially, if one of them has properties that 
match the needs of your protocol. The following were designated as 
core: 


IPsec [RFC 1825] is the basic host-to-host security mechanism. It 
is appropriate for use any time address-—based protection would 
have been used, including with such programs as rsh and rlogin. 
If and when platforms support user-based keying, this scope may 
be expanded. 


One particular technique used by IPsec, HMAC [RFC 2104], is 


more generally useful. If cryptographic authentication but not 
secrecy is needed, and IPsec is not applicable, HMAC should be 
used. 


ISAKMP/Oakley [ISAKMP drafts] is the basic key negotiation 
protocol for IPsec. As such, it should be deployed when IPsec 
is used. With the appropriate "domain of interpretation" 
document, it should be used to negotiate pairwise keys for 
other protocols. 


DNSsec [RFC 2065] is not only crucial for protecting the DNS -- 
cache contamination is the easiest way to launch active attacks 
-—- it’s also needed in many situations when IPsec is used. 


Security/Multipart [RFC 1847] is the preferred way to add secured 
sections to MIME-encapsulated email. 


Signed keys in the DNS. There is, as noted, widespread agreement 
that DNS records themselves must be protected. There was less 
agreement that the key records should be signed themselves, 
making them in effect certificates. Still, this is one 
promising avenue for Internet certificates. 


X.509v3 is the other obvious choice for a certificate 
infrastructure. Again, though, there was no strong consensus 
on this point. 


TLS [TLS draft] was seen by some as the preferred choice for 
transport-layer security, though there was no consensus on this 
point. TLS is less intrusive to the operating system than 
IPsec; additionally, it is easier to provide fine-grained 
protection this way. 
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Li 


Some protocols were designated as "useful but not core". These were 
insufficiently general, too new, or were substantially duplicative of 
core protocols. These include AFT/SOCKS, RADIUS, firewalls, GSS-API, 
PGP, Kerberos, PGP-MIME, PKIX-3, the various forms of per-hop 
authentication (OSPF, RSVP, RIPv2), *POP, OTP, S/MIME, SSH, PFKey, 
IPsec API, SASL, and CRAM/CHAP. Obviously, entries on this list may 
move in either direction. 


A few protocols were considered "not useful". Primarily, these are 
ones that have failed to catch on, even though they’ve been available 
for some time. These include PEM [RFC 1421, 1422, 1423, 1424] and 
MOSS [RFC 1848]. (The phrase "not useful" does not imply that they 
are incorrect, or are lacking in important information. However, 
they do not describe protocols that we are currently encouraging the 
use of.) 


One security mechanism was deemed to be unacceptable: plaintext 
passwords. That is, no protocol that relies on passwords sent over 
unencrypted channels is acceptable. 


Missing Pieces 


Participants in the workshop identified three significant missing 
pieces: object security, secure email, and route security. 


Object security refers to protection for individual data objects, 
independent of transport. We have one such already -- Secure DNS -- 
but we need a me general scheme. MIME is a candidate object 
framework, in part because it is the core of the two most widely used 
and deployed applications: the web and email. However, securing 
email has been problematic and the web is not that far in front. 


Secure email is a critical need and has been for some time. Two 
attempts to standardize secure email protocols (PEM and MOSS) have 
failed to be accepted by the community, while a third protocol (PGP) 
has become a de facto standard around the world. A fourth protocol, 
an industry standard (S/MIME), has been gaining popularity. Both of 
these latter of entered the Internet standards process. 


Route security has recently become a critical need. The 
sophistication of the attackers is on the rise and the availability 
of attacking toolkits has increased the number of sophisticated 
attacks. This task is especially complex because the requirement for 
maximum performance conflicts with the goal of adding security, which 
usurps resources that would otherwise enhance the performance of the 
router. 
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12. Security Considerations 


Security is not and cannot be a cookie cutter process. There is no 
magic pixie dust that can be sprinkled over a protocol to make it 
secure. Each protocol must be analyzed individually to determine 
what vulnerabilities exist, what risks they may lead to, what 
palliative measures can be taken, and what the residual risks are. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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